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Abstract 

Programming is a fundamental skill for Information Systems and Information Technology stu¬ 
dents. It is also a subject that some students fear, avoid, fail, retake, and fail again. An effec¬ 
tive, inexpensive, one-semester approach is presented. Early indications suggest dramatically 
improved student interest and performance compared to our previous two-semester approach. 
Key features include heavy use of web-based online programming, use of a scripting language 
(Perl), development of general-purpose programming skills, and a free textbook (PDF). 
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1. INTRODUCTION 

Programming is a fundamental skill for in¬ 
formation systems and information technol¬ 
ogy students and professionals. Although 
some professionals seldom write a program, 
the skills can come into play in understand¬ 
ing what subordinates do, in writing spread¬ 
sheets, and in automating processes. 

Accreditation standards (ABET, 2008) and 
model computing curriculum recommenda¬ 
tions emphasize the importance of pro¬ 
gramming proficiency, (Shackelford, 2005; 
Gorgone, 2002). However, many of our stu¬ 
dents in IS and IT seem to consider pro¬ 
gramming to be a CS activity, and one they 
would rather avoid. Programming is not 
something these students visualize them¬ 
selves as doing in their future careers. Stu¬ 
dents within the IS and IT programs, there¬ 
fore, have difficulty maintaining engagement 
in computer programming courses. 

Introductory students in these programs of¬ 
ten find programming to be boring and diffi¬ 
cult (Jenkins 2002) and experience high 
rates of failure (Bennedson and Casperson, 


2007). Many students respond to these chal¬ 
lenges by concluding that they are simply 
incapable as programmers (Jenkins 2001). 
These perceptions of incompetence result in 
significant dropout / failure rates in introduc¬ 
tory programming courses and poor perfor¬ 
mance in subsequent programming courses 
(Guzdial and Soloway, 2002). 

Educator responses to these failings include 
believing some students really cannot pro¬ 
gram, thereby lowering expectations of stu¬ 
dent performance (Evans and Simkin 1989), 
attempting to innovate in their teaching 
techniques to promote greater engagement 
(e.g., Leutenneger and Eddington 2007), 
and blaming poor performance on "unmoti¬ 
vated" students (Gill and Holton, 2006). 

In this paper, we outline our experience in 
developing a one-semester approach that 
meets the standards and curriculum recom¬ 
mendations of teaching programming fun¬ 
damentals while creating a learning envi¬ 
ronment in which students can develop 
competence and confidence as emerging 
programmers. The preliminary results of this 
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approach suggest that student performance 
and perceptions of computer programming 
have improved significantly. We anticipate 
that the lessons learned in our experience 
will be helpful to educators attempting to 
address these issues in their local institu¬ 
tions. 

2. THE WAY WE WERE 

Many of our students in IS and IT seem to 
consider programming to be a CS activity, 
and one they would rather avoid (much like 
Calculus). Despite accreditation standards 
and model curriculum recommendations, it 
is not something they visualize themselves 
doing as part of their job. We have to sell it 
well for students to decide to really engage 
in learning. 

Some years ago we set the bar fairly low. 
Students read and discussed simple pro¬ 
grams but did not actually write them. Some 
teachers were afraid that students would 
fail, become discouraged, and change ma¬ 
jors. Such an overview did not give students 
adequate programming skills to actually do 
even small-scale projects. 

We tried setting the bar higher, with a long, 
shallow learning curve, using a two- 
semester approach and numerous micro¬ 
projects (Colton et al, 2005; Colton et al 
2006). It worked much better. Most students 
developed skills but were not eager to use 
them. For them programming was tedious 
instead of fun. 

We looked at other approaches but were put 
off by the high proportion of "magic" that 
seemed to be involved. By magic we mean 
that students developed skills that work 
marvelously well in a small number of set¬ 
tings but did not transfer to more general 
settings. This felt like "training" instead of 
"education." 

Finally we abandoned a key element of our 
two-semester sequence, creating in its place 
a new two-semester sequence. As the 
change worked its way through the system, 
we discovered some useful economies that 
led eventually to the development of a sin¬ 
gle, one-semester programming course. 

2.1 The Two-Semester Sequence 

Our department hosts three majors: Com¬ 
puter Science, Information Systems, and 
Information Technology. Where possible, 


courses are made to serve more than one 
major. The introductory programming class 
is taken by students in all three majors. 

(One goal of the introductory programming 
class is to help computing students select 
the major that will best suit them. As fresh¬ 
men, students often do not understand the 
differences between CS, IS, and IT. Seeing 
all three types of students in the same class 
helps students self-identify more accurate¬ 
ly.) 

We used C in CIS 101 as our foundational 
language. This choice was motivated by sev¬ 
eral factors. First, C is well known and highly 
respected. Second, C is small enough to be 
well understood. Third, programming skills 
seem to transfer well from C to other lan¬ 
guages students may need to learn later. 
Fourth, the class was to be taught by CS 
faculty and C or C++ or Java was their lan¬ 
guage of choice. C (C++) seemed easiest. 

The learning objective from the CIS 101 
course was that students be proficient with 
variables and data types (int, float, char) 
and be introduced to arrays, and that they 
be proficient with if/else and loops (while, do 
while, for) and be introduced to subroutines. 

We used Perl in CIS 201 as our follow-on 
language. (For those unfamiliar with Perl, 
Appendix B gives a few short example pro¬ 
grams written in this language.) This choice 
was also motivated by several factors. 
Scripting languages (like Perl, Python, and 
Ruby) are much faster for completing small- 
to medium-sized programming projects. 
Scripting skills are important for CS, IS, and 
IT students. Among scripting languages, Perl 
is well known and highly respected. It is not 
small like C, but it has a large body of open 
source shared archives (since 1995, the 
Comprehensive Perl Archive Network at 
http://CPAN.org/ '). 

The learning objective from the CIS 201 
course was that students transfer all their 
CIS 101 skills to Perl, thus seeing how easy 
it is to learn a second language, and in addi¬ 
tion become skilled at database access and 
online programming (CGI) on a Linux plat¬ 
form. This also created the opportunity to 
introduce and develop skill with regular ex¬ 
pressions. The capstone project was to build 
from scratch a small online store complete 
with shopping cart and inventory system. 
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2.2 Mistaken Assumptions 

We assumed that after learning C for a 
semester, students would find it easy to 
learn Perl. They would conclude that it would 
be easy to learn additional languages later, 
as needed. This confidence was a major goal 
of using two different languages. 

Unfortunately, for IS and IT students the 
single semester of C did not result in ade¬ 
quate programming skills on which to 
springboard into another language. Students 
had to relearn everything and the learning 
speed was only slightly faster than the first 
time they learned it. 

In CIS 201, it was too easy to become fru¬ 
strated by the slowness of students in de¬ 
monstrating skills they should have already 
mastered. It was too easy to blame the CIS 
101 teacher for failing to teach. It was too 
easy to blame the students for being stupid. 
In retrospect, it appears the problem was 
the course design in CIS 101. There was a 
mismatch between the expectations in CIS 
101 and the abilities and interests of the 
students in CIS 101. 

It was not immediately obvious, but instead 
of having two semesters of programming, 
students were having one semester of pro¬ 
gramming, twice. The synergy was missing. 

3. TIPPING POINT 

There were other frustrations with the exist¬ 
ing programming sequence. The CS faculty 
did not see enough value in the CIS 201 
class and wanted to remove their students 
from it, substituting an additional semester 
of Java. CS was one of the longest majors 
on campus in terms of credit hours, and felt 
the need to add new courses but also 
wanted to abandon old courses of limited 
value. 

This gave rise to the question of whether CS 
students should learn a scripting language at 
all. It was decided that there was still a real 
need for scripting in CS. A suggestion was 
then made by CS to convert the CIS 101 
class over to scripting. It was a totally unex¬ 
pected suggestion, but it quickly developed 
broad support. The new approach would be 
to teach scripting in CIS 101 to all students, 
and more advanced scripting in CIS 201 to 
just the IS students. IS students would fore¬ 
go the learning of C. 


The Resulting Curriculum 

Starting August 2008 we converted the CIS 
101 course into Perl and merged in the ma¬ 
jor features of the old CIS 201 class. 

Under the old plan, the 201 class spent 1/3 
of its time reviewing basic concepts from 
101 but recasting them in the light of Perl. 
The next 1/3 of the course was online pro¬ 
gramming. The final 1/3 of the course was 
database using mySQL and simple queries 
(select, insert, update, no joins). Under the 
new plan it was hoped that the first 1/3 of 
the course would no longer be needed and 
new material could be added. 

Because there were already students in the 
pipeline, in Fall 2008 both 101 and 201 were 
taught in Perl. In Winter 2009 the 201 stu¬ 
dents included some who had learned Perl 
before as well as some that had only learned 
C before. But over the course of Fall and 
Winter we made some interesting discove¬ 
ries. 

The immediate results were very interesting. 
During the first semester after the change, 
CIS 101 and CIS 201 were taught by the 
same instructor. CIS 101 students learned 
Perl as their first language, and CIS 201 
students learned Perl for the first time, but 
as their second language. Remarkably, the 
101 students did nearly as well as the 201 
students. 201 students continued to perform 
largely as before. Also, CIS 101 students 
gave the teacher high ratings and CIS 201 
students gave the teacher lower ratings. 

Table 1 (in the Results section below) 
presents results in terms of learning objec¬ 
tives mastered by 101 and 201 students re¬ 
spectively. It shows that for many objec¬ 
tives, the top 90% of 101 students per¬ 
formed at the same level as 201 students. 

Several theories emerged to explain this 
phenomenon. (1) Perhaps 201 students 
were frustrated that they were being asked 
to learn a second language when their first 
language had been boring. This frustration 
was realized as push-back against the 
course and decreased learning. (2) Perhaps 
201 students had not learned C well enough 
that the programming skills were transferra- 
ble to a new language yet. 

Whatever the reason (both seem to be 
plausible), it called into question our old 
theories about how best to teach program- 
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ming. It was concluded by the faculty that if 
101 students could perform at roughly a 201 
level, then the 201 course was not needed. 

It was decided to do away with CIS 201 and 
create instead a new capstone CIS 401 web 
programming course involving additional 
prerequisites and featuring the PHP lan¬ 
guage. The new course would have as pre¬ 
requisites courses in webpage development 
(xhtml, css) and in database (SQL including 
join). This would allow greater development 
of marketable skills for our students. 

CIS 201 was taught for the last time in May 
2009. CIS 401 is being taught for the first 
time in September 2009. 

4. PROGRAMMING IN ONE 
SEMESTER 

The new model is for all things programming 
to be taught in CIS 101 such that students 
emerge with programming proficiency to the 
degree expected of IS graduates. That is a 
tall order, but we try to deliver on it by using 
the following approach. 

First, students learn a single language. We 
teach them Perl but keep it simple, at least 
at first, in hopes that the skills will be trans¬ 
ferable to any other language they may 
need to learn. There is a great emphasis on 
portability of approach, skills, and know¬ 
ledge. (For those unfamiliar with Perl, ap¬ 
pendix B gives a few small sample pro¬ 
grams.) 

Second, we wrote our own textbook. This 
was a major step, not undertaken lightly, 
and not something we recommend to every¬ 
one. But the book, version 1.0, is in use and 
freely available to other schools for adoption 
as a primary text or as a supplement. 

Third, we strongly emphasized online pro¬ 
gramming. We found that students respond 
enthusiastically to having their programs run 
on the web and being able to share them 
with friends near and far. At the same time 
we were very cautious to not delve too much 
into magic, where students do not really un¬ 
derstand what they are doing but look up 
recipes in some index. This was greatly faci¬ 
litated by having our own textbook. 

4.1 Single Language 

Ideally we might teach the language that all 
future employers will demand. Unfortunate¬ 


ly, employers have not converged on a stan¬ 
dard. Fortunately there are some favorite 
languages among employers, and most of 
these are similar to one another. We hope to 
teach a language that will be an easy basis 
for students to go on to other languages as 
their circumstances may demand. 

We generally agree that any of several 
scripting languages could be used effective¬ 
ly. Our current choice is Perl. Factors in lan¬ 
guage selection include being typical, power¬ 
ful, well known, portable, and well sup¬ 
ported. 

Typical: By this we mean that skills transfer 
well to other programming languages. 

Powerful: By this we mean useful programs 
can be written fairly easily with the level of 
skill our students would achieve. 

Well Known: By this we mean employers 
have heard of it, so it could be meaningfully 
listed on a resume. 

Portable: By this we mean programs writ¬ 
ten for the Linux platform will also work on 
Microsoft or Macintosh and vice versa. 

Well Supported: By this we mean there is 
a large user community that is actively help¬ 
ing each other and there are large collec¬ 
tions and archives of program libraries avail¬ 
able to everyone. 

4.2 Textbook 

Our textbook, Introduction to Programming 
Using Perl, is available free online as a PDF 
file at http://ipup.doncolton.com/ . 

The book is designed to support an introduc¬ 
tory (100-level) college course that meets 
for about forty hours during a semester or 
quarter. 

The book contains about 60 chapters divided 
into eight units for a total of about 340 pag¬ 
es. Most of the early chapters are designed 
to be read at the rate of one to two chapters 
per hour of time in the classroom. 

We assume that students are not yet con¬ 
vinced of the importance of programming 
and may be taking the class simply because 
it is required. We motivate their study by 
emphasizing questions of "why" as well as 
showing "how." We focus on introductory 
issues. 


© 2010 EDSIG 


http://isedj.org/8/48/ 


July 12, 2010 




ISEDJ 8 (48) 


Colton and Curtis 


7 


Advanced topics are usually mentioned brief¬ 
ly but with enough detail that students can 
follow up by searching the Internet. We as¬ 
sume the students of today are skillful at 
using search engines and other tools to get 
in-depth answers on topics of interest to 
themselves, once they know the topics exist 
and what they are called. 

4.3 Online Programming 

Our students turned out to be VERY enthu¬ 
siastic about online programming. We be¬ 
lieve this is for two reasons, (a) It allows 
them to share their work with friends and 
family anywhere in the world, (b) It allows 
them to integrate graphical elements easily. 

During the first semester of our new course, 
we deferred online programming until almost 
the end of the semester because of the diffi¬ 
culty of parsing online input. Enthusiastic 
student response to online programming 
made us to look for ways to teach online 
skills earlier in the course. 

The downsides of online programming are 
(a) the difficulty of maintaining state (con¬ 
versation), and (b) the difficulty of working 
with "open set" input. (Restricted, "canned," 
or "closed set" input turns out to be easily 
handled.) 

We reorganized the course to give students 
very early success at creating online pro¬ 
grams, starting from a simple graphics pro¬ 
gram that rolls dice or tosses a coin, and 
continuing closed set inputs, and finally 
reaching open set inputs through regular 
expressions. 

Rolling dice or tossing coins requires very 
little beyond the "Hello, World" level of pro¬ 
gramming. We need only include a lesson on 
random numbers. The results are imme¬ 
diately impressive. Students have something 
to show off within the first two weeks of the 
semester. If/else is not required. Loops are 
not required. Subroutines are not required. 

Closed-set input allows programs to respond 
to button presses. Because there are only a 
few possible inputs to consider, they can be 
handled through an explicit series of if/else 
statements. One classic game we program is 
Rock Paper Scissors, where the human 
pushes a button for one of the three, the 
computer program randomly selects one of 
the three, and a series of if/else statements 
resolve the winner. Graphics are included to 


improve the appeal of the program. We find 
this can be done by around the fourth week 
of a 14-week class. 

Open-set input requires the use of myste¬ 
rious library functions or an understanding of 
regular expressions. We take advantage of 
the opportunity to introduce regular expres¬ 
sions. However, because of the complexity 
involved, we feel this cannot be well done 
until about week 10 of a 14-week class. 

5. LEARNING OBJECTIVES 

Our learning objectives have been designed 
to be realistic for 80 percent of our students. 

We do not assume any prior programming 
knowledge or experience. We do assume 
students have math skills to do simple alge¬ 
bra (solve x - 7 = 3) and that they have 
access to a computer with Perl installed. 

5.1 Basic Expectations 

Our standard is that basic material must be 
mastered so later courses can build on it. 
This is not a survey course or a high-level 
overview like, say. Art Appreciation. It is a 
"do it" class like, say, Drawing. 

Because programming must become a basis 
on which other courses can build, we meas¬ 
ure student performance on closed-book 
programming tests. 

Mastery is divided into five topics: basics, 
decisions, iteration, arrays, and subroutines. 
By the end of the semester, students must 
master the first two topics to pass the class 
(with a D). They must master the first three 
to get a C. They must master all five to get a 
B. They must also demonstrate ability with 
some advanced material to earn an A. 

Basics: Students write correct programs 
that use standard input and output to get 
information into and out of the computer. 
Programs run from a Graphical User Inter¬ 
face (GUI) or from a Command Line Inter¬ 
face (CLI). Students demonstrate the ability 
to use normal (scalar) variables to do calcu¬ 
lations such as inches to centimeters. Stu¬ 
dents use fundamental mathematical opera¬ 
tors including add, subtract, multiply, divide, 
and parentheses. Students understand that 
statements are executed in order, one after 
another, and that later statements can 
change the values of variables from what the 
earlier statements established. We introduce 
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style rules including naming of variables and 
spacing of written programs. 

Decisions (if/elsif/else): Students write 
correct programs that deal differently with 
alternate cases, such as whether to put AIM 
or PM after the time, or whether a check will 
be honored or will bounce. This includes skill 
with Boolean operators (those yielding a 
True or False answer) such as comparatives 
(less than, greater than, equal to, not equal 
to) and conjunctives (and, or). This also in¬ 
cludes following style rules of indentation 
and spacing to make complex programs 
more readable. 

Loops (Repeated Actions): Students write 
correct programs that deal with repetition of 
actions, such as filling out a table. Style is 
also emphasized. Operators like ++ and + = 
are mastered, next, last, and redo are in¬ 
troduced. 

Arrays/Lists (Repeated Data): Students 
write correct programs that deal with lists of 
information. The foreach loop is mastered, 
push, pop, shift, unshift, and indexing 
([ 1 ] and [- 1 ]) are mastered. 

Organizing (Subroutines, Functions, Me¬ 
thods, Objects): Students correctly write 
subroutines to better organize and structure 
their code. Local and global scope of va¬ 
riables is understood. 

5.2 Proving Mastery 

To prove mastery students are given a Final 
Exam that has five sections (one per topic 
area) each with several programs of varying 
difficulty. Students must correctly write 
those programs in a topic area before we 
consider it to be mastered. 

(We chose to do this instead of having eve¬ 
ryone do a major project for the unfortunate 
reason that too many students were turning 
in project work they did not understand. 
They were apparently turning in someone 
else's work as their own. However, once a 
student demonstrates adequate mastery on 
exams, we DO utilize a term project as a 
way to motivate the A students and separate 
them from the B students.) 

A large number of sample problems from the 
Final Exams are given in the free PDF text¬ 
book. 

Because students do not all learn at the 
same rate, we do not care when students 


demonstrate mastery as long as it is by the 
last day of class. The jury is still out on how 
much this simply invites students to procras¬ 
tinate. 

The course grade is based almost totally on 
the final exam, so little else really matters. 
This takes the teeth out of midterms and 
homework assignments. What do we do 
about that? An all-or-nothing final can be 
pretty scary. So we compromise by giving 
the Early Final. 

5.3 The Early Final 

About once a week we offer an actual final 
exam. The questions are different each time, 
but are basically the same or of the same 
difficulty. The rule is that if a student passes 
any section of the exam, they don't have to 
take that section again. This gives them a 
reason to take the tests and to make 
progress. The entire final is too much to take 
on the last day of class. Knowing that part of 
the final is completed seems to be a good 
motivator. 

Toward the start of the semester, the weekly 
exam covers only material already studied in 
class, so it is much shorter than it will even¬ 
tually become. We allow about ten minutes 
for the test for the first few weeks. As more 
material is covered in class, new sections 
are added, making the test longer. Student 
performance also spreads out, with some 
students having completed the early sec¬ 
tions while other students continue to strug¬ 
gle. We increase the amount of time allowed 
to 20 or 30 minutes. The last few weeks of 
the semester we allow the full class period 
once a week for the exam. 

Because each Early Final is actually the real 
final, all the normal rules apply. The exams 
are closely proctored and performance must 
be at a final-exam level. Toward the start of 
the semester very few students pass any¬ 
thing. Toward the end many students are 
passing things. 

The unit tests throughout the textbook give 
actual test questions that have been used in 
the Finals to assess mastery of each topic. 
Students are also allowed to keep a copy of 
the exam and the work they did. One day 
later they can share their efforts with each 
other. 

During the exams we allow the students to 
test their work by running it at their local 
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machine. However, they are not allowed to 
use any notes or outside resources, includ¬ 
ing web pages. They are only allowed to test 
their programs by running them locally. If 
there are reference materials we wish to 
make available, we put them in the test it¬ 
self. 

Scoring: We grade programs "by hand," vi¬ 
sually examining the student code. In addi¬ 
tion to working, we expect student programs 
to demonstrate the requested programming 
style (indentation, spacing, comments, nam¬ 
ing) to make the programs easy to read and 
understand. 

6. RESULTS 

It is probably not possible to give definitive 
results given the small sample size, but pre¬ 
liminary results are encouraging. The follow¬ 
ing table gives the percentage of students 
achieving 100 % in each level of skill during 
our Winter 2009 term. Winter represents the 
main transitional term, where students in 
201 had a previous term probably in a dif¬ 
ferent language. We do not have directly 
comparable performance metrics for 101 
students under the old plan. 

Nearly identical final exams were used 
across all sections of both courses. The 
same textbook was used in all courses. The 
same instructor taught all sections. The 
101/201 column tells how well the 101 stu¬ 
dents did as a group compared to the 201 
students. 


Table 1: Mastery of Learning Objectives 


Skill 

101 

201 

101/201 

Basics 

93% 

96% 

97% 

if / else 

83% 

92% 

90% 

Iteration 

72% 

80% 

90% 

Arrays 

29% 

32% 

91% 

Subroutines 

9% 

16% 

56% 

Online Skills 

28% 

24% 

117% 

Term Project 

3% 

20% 

15% 

N (students) 

58 

25 



Performance on basics, if/else, iteration, ar¬ 
rays, and online skills was all at the 90% or 
better level for the group of 101 students 
compared to the 201 students. 


With subroutines, only half as many 101 
students performed at the 201 level. With 
term projects, only a small fraction per¬ 
formed at the 201 level. 

The online skills section is noticeably better 
for the 101 students, but this may not be 
statistically significant given the small sam¬ 
ple size. It seems however to suggest that 
101 students may have been riding a wave 
of excitement while 201 students were fight¬ 
ing pre-conceived notions of whether it 
would be interesting. 

7. INSTRUCTOR RESPONSE 

The primary author of this paper also wrote 
the textbook. His experience has been that it 
is wonderful to control the textbook in such 
an intimate way because it allows the book 
to be adjusted from time to time to match 
the performance of the students and to re¬ 
spond to the difficulties they face. However, 
writing a textbook is a major commitment 
and takes a lot of time. 

Another instructor to teach a full course us¬ 
ing the book responded: "I really liked the 
format and pace of the class. I would like to 
extend [the book's coverage] into [the next 
CS class] as well." 

8. CONCLUSIONS 

Online programming is HIGHLY motivational 
to students because it facilitates sharing 
their achievements and allows graphical and 
other creative elements to be involved. 

Programming proficiency seems to be 
achievable in a one-semester course that is 
well structured and adequately supported. 

A free textbook (PDF) is available for use as 
a primary text or as a supplementary text in 
classes such as this. 
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APPENDIX B 

Brief examples of Perl. 

Following are some short programs in Perl to 
give a flavor for the language for those that 
may not be familiar with it. 

Basic I/O 

Print the words “Hello, World!” 

print "Hello, World!\n" 

Read in a name. Print on one line “I think 
(name) is nice.” 

$name = <STDIN>; 
chomp ( $name ) ; 

print "I think $name is nice.Xn" 

Simple Calculation 

Read in two numbers. Print their total. 

$ x = <STDIN>; 

$y = <STDIN>; 

$z = $x + $y; 
print "$z\n"; 

Simple Decision 

Read in a number. If greater than 10 print 
“Big”. If less than 5 print “Small”. Otherwise 
print “Medium”. 

$ x = <STDIN>; 

if ( $x > 10 ) { print "Big" } 
elsif ( $x < 5 ) { print "Small" } 
else { print "Medium" } 

Iteration 

Read in a number. Print the numbers from 1 
up to the number read in. 

$max = <STDIN>; 

for ( $i = 1; $i <= $max; $i++ ) { 

print "$i\n" } 

Array by Index 

Given an array abc, print the fifth element. 

print "$abc[4]\n"; 

Given an array abc, print the next to last ele¬ 
ment. 

print "$abc[-2]\n"; 


Subroutine 

Write a subroutine abc that accepts two pa¬ 
rameters and returns the sum of them. 

sub abc { 

my $x, $y, $z; 

( $ x, $y ) = @_; 

$z = $x + $y; 
return $z } 

Online (CGI) 

Write a program that rolls two dice and dis¬ 
plays the results in a web browser. (Notice 
that the html is barely adequate. We teach 
html in a different course.) This presumes that 
1.jpg through 6.jpg are available to display. 
rand(6) returns a uniformly distributed random 
number between 0.00 and 5.99. 

print "content-type: text/html\n\n"; 
$dl = int ( rand(6) ) + 1; 

$d2 = int ( rand(6) ) + 1; 
print "<img src='$dl.jpg'>"; 
print "<img src='$d2.jpg'>"; 
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